home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000029_timbl _Thu Jan 9 12:34:24 1992.msg < prev    next >
Internet Message Format  |  1994-01-24  |  42KB
  1. Return-Path: <timbl>
  2. Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA08666; Thu, 9 Jan 92 12:34:24 GMT+0100
  4. Date: Thu, 9 Jan 92 12:34:24 GMT+0100
  5. From: timbl (Tim Berners-Lee)
  6. Message-Id: <9201091134.AA08666@ nxoc01.cern.ch >
  7. Received: by NeXT Mailer (1.62)
  8. To: Mark Alexander Davis-Craig <mad@merit.edu>
  9. Subject: Re: Is there a paper which describes the www protocol?
  10. Cc: www-talk
  11.  
  12.  
  13.  
  14. > From: Mark Alexander Davis-Craig <mad@merit.edu>
  15. > 
  16.  
  17. > I was looking through the web and found information on servers and
  18. > clients.  I saw mention in the "History" section about wanting to
  19. > develop a good protocol for information exchange, but haven't seen a
  20. > paper specifically about the www protocol.  Is there one?  If not,
  21. > could you describe it in some detail?
  22.  
  23. You are right that the protocol documentation was not as good as it could
  24. have been. I have improved it. To save you browing through the web for it,
  25. I append to this message the information as plain text.
  26.  
  27. > I ask because we at the University of Michigan are evaluating www,
  28. > wais, and gopher for campus-wide information delivery.
  29. >
  30.  
  31. I have no need to tell you what our suggestion would be!  The W3 architecure
  32. will give you (almost) everything you can get from WAIS and Gopher rolled into one.
  33. The trick is that almost anything is representable by hypertext links and index searches. The  
  34. Gopher menus and plain text, for example, are both special cases of hypertext.  As it is more  
  35. work to do the job for hypertext in general, we do not yet have software to cover as many  
  36. platforms as Gopher, for example. However, when we do, the W3 system will be more flexible.   
  37. Running a W3 server on top of a WAIS or Gopher world in fact makes these worlds subsets of the W3  
  38. web. The reverse is not possible because the WAIS and Gopher information models are not flexible  
  39. enough
  40. to encompass the W3 model.
  41.  
  42. That said, if you want an indexer we can only recommend the wais code (or NeXT code) and we do  
  43. not yet supply (as Gopher does) an off-the shelf index server for either of those indexes yet. It  
  44. is easy to do, however, with our generic server code.
  45.  
  46. Please keep me informed of your thinking, whether you plan to go W3 or Gopher.  If we can help  
  47. you set up a demonstration system, then mail me.
  48.  
  49.  
  50. >Thanks in advance.
  51. >  -----------------------------------------------------------------
  52. >  Mark Davis-Craig, Merit/MichNet Technical Support Consultant
  53. >  mad@merit.edu        mad@merit.bitnet        (313)-936-2110
  54.  
  55.  
  56. Tim Berners-Lee                       timbl@info.cern.ch
  57. World Wide Web project                (NeXTMail is ok)    
  58. CERN                                  Tel: +41(22)767 3755
  59. 1211 Geneva 23, Switzerland           Fax: +41(22)767 7155
  60.  
  61. _________________________________ protocol notes follow ___________
  62.  
  63.  
  64.                                          The HTTP Protocol As Implemented In W3
  65.  
  66.  
  67.                           HTTP AS IMPLEMENTED IN WWW
  68.                                        
  69.  
  70.    This document defines the Hypertext Transfer protocol  (HTTP) as currently
  71.    implemented by the WorldWideWeb initaitive software. This is a subset of the
  72.    proposed full HTTP protocol.  No client profile information is transferred
  73.    with the query. Future HTTP protocols will be back-compatible with this
  74.    protocol.
  75.    
  76.  
  77.     The protocol  uses the normal internet-style telnet protocol style on a
  78.    TCP-IP link. The following describes how a client acquires a (hypertext)
  79.    document from an HTTP server, given an HTTP document address .
  80.    
  81.  
  82. Connection
  83.  
  84.    The client makes a TCP-IP connection to the host using the domain name or IP
  85.    number , and the port number  given in the address.
  86.    
  87.  
  88.     During development, the default HTTP TCP port number is 2784 -- this will
  89.    change when an official port number is allocated.
  90.    
  91.  
  92.     The server accepts the connection.
  93.    
  94.  
  95.     Note: HTTP currently runs over TCP, but could run over any
  96.    connection-oriented service.   The interpretation of the protocol below in
  97.    the case of a sequenced packet service (such as DECnet(TM) or ISO TP4) is
  98.    that that the request should be one TPDU, but the repose may be many.
  99.    
  100.  
  101. Request
  102.  
  103.    The client sends a document request consisting of a line of ASCII characters
  104.    terminated by a CR LF (carriage return, line feed) pair. A well-behaved
  105.    server will not require the carriage return character.
  106.    
  107.  
  108.     This request consists of the word "GET", a space, the document address ,
  109.    omitting the "http:, host and port parts when they are the coordinates just
  110.    used to make the connection. (If a gateway is being used, then a full
  111.    document address may be given specifying a different naming scheme).
  112.    
  113.  
  114.     The search functionality of the protocol lies in the ability of the
  115.    addressing syntax to describe a search on a named index .
  116.    
  117.  
  118.     A search should only be requested by a client when the index document
  119.    itself has been descibed as an index using the  ISINDEX tag .
  120.    
  121.  
  122. Response
  123.  
  124.    The response to a simple GET request is a message in hypertext mark-up
  125.    language ( HTML ). This is a byte stream of ASCII characters.
  126.    
  127.  
  128.     Lines shall be delimited by an optional carriage return followed by a
  129.    mandatory line feed chararcter. The client should not assume that the
  130.    carriage return will be present.  Lines may be of any length. Well-behaved
  131.    servers should retrict line length to 80 characters excluding the CR LF
  132.    pair.
  133.    
  134.  
  135.     The format of the message is HTML - that is, a trimmed SGML document. Note
  136.    that this format allows for menus and hit lists to be returned as hypertext.
  137.    It also allows for plain ASCII text to be returned following the  PLAINTEXT
  138.    tag .
  139.    
  140.  
  141.     The message is terminated by  the closing of the connection by the server.
  142.    
  143.  
  144.     Well-behaved clients will read the entire document as fast as possible. The
  145.    client shall not wait for user action (output paging for example) before
  146.    reading the whole of the document.  The server may impose a timeout of the
  147.    order of 15 seconds on inactivity.
  148.    
  149.  
  150.     Error responses are supplied in human readable text in HTML syntax. There
  151.    is no way to distinguish an error response from a satisfactory response
  152.    except for the content of the text.
  153.    
  154.  
  155. Disconnection
  156.  
  157.    The TCP-IP connection is broken by the server when the whole document has
  158.    been transferred.
  159.    
  160.  
  161.     The client may abort the transfer by breaking the connection before this,
  162.    in which case the server will not record any error condidtion.
  163.    
  164.  
  165.     Requests are idempotent .  The server need not store any information about
  166.    the request after disconnection.
  167.    
  168.  
  169.     _________________________________________________________________
  170.    
  171.  
  172.                                                                          Tim BL
  173.                                                                                
  174.  
  175.                                W3 NAMING SCHEMES
  176.                                        
  177.  
  178.    (See also: a discussion of design issues involved , BNF syntax , W3
  179.    background)
  180.    
  181.  
  182.     The format of a hypertext name consists of the name of the naming
  183.    sub-scheme to be used, then a name in a format particular to that subscheme,
  184.    then an optional anchor identifier within the document. For example, the
  185.    format is for all internet-based access methods:
  186.    
  187.  
  188.       scheme : // host.domain:port / path / path  # anchor
  189.    
  190.  
  191.     A suffix # anchor id allows one to refer to a particular anchor within a
  192.    document.
  193.    
  194.  
  195.     A suffix ? followed by words separated by + signs  allows one to seach an
  196.    index (see details ).
  197.    
  198.  
  199.     References from one document to another with a similar name may be
  200.    abbreviated to a relative name . This imposes certain restrictions on the
  201.    way that the "path" is represented.
  202.    
  203.  
  204.     A special format is used to represent a search on an index . See also: the
  205.    full BNF description , about escaping illegal characters .
  206.    
  207.  
  208. Examples
  209.  
  210.  
  211.          file://cernvax.cern.ch/usr/lib/WWW/defaut.html#123
  212.  
  213.    This is a fully qualified file name, referring to a document in the file
  214.    name space of the given internet node, and an imaginary anchor 123 within
  215.    it.
  216.    
  217.  
  218.  
  219.          #greg
  220.  
  221.    This refers to anchor "greg" in the same document as that in which the name
  222.    appears.
  223.    
  224.  
  225. Naming sub-schemes
  226.  
  227.    Different schemes usually use different protocols on the network. The format
  228.    of the address after the scheme name is a function of the particular scheme.
  229.    In practice, all internet-based schemes have a common format for the node
  230.    name and port.   Schemes currently defined are as follows, with links to
  231.    more details.
  232.    
  233.  
  234.   file                    Access is provided to files, using whatever means the
  235.                          browser and/or gateways have to reach files on obscure
  236.                          machines.
  237.                          
  238.  
  239.   news                    Access is provided to news articles, and newsgroups,
  240.                          normally using the NNTP protocol.
  241.                          
  242.  
  243.   http                    Access is provided to any other information using the
  244.                          HTTP search and retrieve protocol . The internal
  245.                          addressing of the information system is mapped onto a
  246.                          W3 path.
  247.                          
  248.  
  249.   telnet                  Access is provided by an interactive telnet session.
  250.                          This is provided ONLY as an interface to other
  251.                          existing online systems which cannot or have not been
  252.                          mapped onto the W3 space.
  253.                          
  254.  
  255.   gopher                  Access is provided using the "gopher" protocol. The
  256.                          gopher protocol is similar to HTTP but uses separate
  257.                          concepts of menus and text files rather than
  258.                          hypertext.
  259.                          
  260.  
  261.    Other schemes we foresee are wais and x500.  Systems (such as WAIS) which
  262.    are not currently accessed directly be W3 servers may be accessed though
  263.    gateways, in which case the document address is encoded within the http
  264.    address of the document in the gateway.  Browsers which do not have the
  265.    ability to use certain protocols may (in principle) be configured to
  266.    automaticaly use certain gateways for certain addressing schemes.
  267.    
  268.  
  269.     This will allow, for example, simple PC-based clients to follow links
  270.    through X500 name servers.
  271.    
  272.  
  273.                                 RELATIVE NAMING
  274.                                        
  275.  
  276.    The address of a hypertext document is normally given within the context of
  277.    another hypertext document. Where the addresses of the two documents are the
  278.    similar, this allows only the difference between the two names to be given,
  279.    saving space. An example is the address of the destination of a hypertext
  280.    link , which is specified relative to the source document address.
  281.    
  282.  
  283.     (A futher practical advantage is that a group of documents may be
  284.    transmitted without internal changes, or accessed using more than one
  285.    address.)
  286.    
  287.  
  288.     In the WWW address format , the rules for relative naming are:
  289.    
  290.  
  291.        If the "scheme" parts  are different, the whole absolute address must be
  292.           given. Other wise, the scheme is omitted, and:
  293.           
  294.  
  295.        If the "host" and/or "port" parts are the different, the host name and
  296.           all the rest of the address must be given. The host name may be given
  297.           using internet hostname conventions, ie domains may be omitted where
  298.           different. This is not very well defined:  one tends to assume that
  299.           if any dot is present, then the full domain name is being given, up
  300.           to the root (.) domain, while if there are no dots, the domain is the
  301.           same as that of the hostname part of the the base address.
  302.           
  303.  
  304.        If the access and host parts are the same, then the path may be given
  305.           with the unix convention, including the use of  ".." to mean indicate
  306.           deletion of a path element. Within the path:
  307.           
  308.  
  309.        If a leading slash is present, the path is absolute. Otherwise:
  310.           
  311.  
  312.        The last part of the path of the base address (e.g. the filename of the
  313.           current document) is removed, and the given relative address appended
  314.           in its place.
  315.           
  316.  
  317.        Within the result,  all occurences "xxx/.."  are recursively removed,
  318.           where xxx is one path element (directory).
  319.           
  320.  
  321.    The use of the slash "/" and double dot ".." in this case must be respected
  322.    by all servers. If necessary, this may mean converting their local
  323.    representations in order that these characters should not appear within path
  324.    elements (see "escaping").
  325.    
  326.  
  327.                           ADDRESS FOR AN INDEX SEARCH
  328.                                        
  329.  
  330.    If a given hypertext node is an index, or the server has an index associated
  331.    with it, then a search may be done on that index by suffixing the name of
  332.    the index with a list of keywords, after a question mark:
  333.    
  334.  
  335.  
  336.         address_of_index ? keywordlist
  337.  
  338.    The address of the index is a normal hypertext address. In the keuwordlist,
  339.    multiple keywords are separated by plus signs (+) .  (See BNF syntax
  340.    description .)  The resulting string still does not contain any spaces. It
  341.    may be considered to be the hypertext address of a document which is the
  342.    result of making the keyword search on the index. Normally, if the search
  343.    was successful, the document returned will contain anchors leading to other
  344.    documents which match the selection criteria.
  345.    
  346.  
  347.     The search method, and the logical and lexical functions, weights, etc
  348.    applied to the keywords will depend on the index address.  One actual index
  349.    may have several hypertext addresses,  which when searched on will behave in
  350.    different ways. For example, one may allow a search on author-given keywords
  351.    only, while another may be a full text search.  These things particular to
  352.    an index should be descibed in the hypertext page for the index node itself
  353.    (or in linked documents). For example, a server may allow specific boolean
  354.    search combinations may be represented by the words "and", "or" and "not".
  355.    
  356.  
  357. Example:
  358.  
  359.  
  360.                 http://cernvm/FIND/?sgml+cms
  361.  
  362.    indicates the result of perfoming a search for keywords "sgml" and "cms" on
  363.    the index http://cernvm/FIND/.
  364.    
  365.  
  366.                                 HTTP ADDRESSING
  367.                                        
  368.  
  369.    With an access code of http:,  a protocol introduced for  the WWW initiative
  370.    is used to acquire data from a server. This is the "Hypertext Transfer
  371.    protocol", HTTP , a simple search and retrieve (S and R) protocol.
  372.    
  373.  
  374.     The syntax of an http address is, with [] indicating optional parts (see
  375.    BNF description ),
  376.    
  377.  
  378.  
  379.         http : // hostname [ : port ] / path [ ? searchwords ]
  380.  
  381.    for example, the following are valid addresses:
  382.    
  383.  
  384.  
  385.         http://info.cern.ch/hypertext/WWW/TheProject.html
  386.  
  387.         http://crnvmc.cern.ch/FIND?sgml+examples
  388.  
  389.    HTTP addresses conform to the WWW conventions,  including the possibility of
  390.    using the search format . The significance of the items in the path part of
  391.    the document name is completely up to the server. Different paths may be
  392.    used to select different databases, different views of the same database,
  393.    etc.
  394.    
  395.  
  396.   hostname                This is the name of the server in internet form. A
  397.                          numeric form (e.g. 128.141.201.74) may be used, by the
  398.                          domain name form (e.g. info.cern.ch) is preferred. The
  399.                          hostname is mandatory.
  400.                          
  401.  
  402.   port                    This is a numeric port number. If a non-numeric
  403.                          string is used, it must be a defined service name.
  404.                          Note that as there is no central repository for
  405.                          service names (they are defined locaaly for each
  406.                          host), a service name is NOT an appropriate way to
  407.                          specify a port number for a hypertext address. If the
  408.                          port number is omitted the preceding colon must also
  409.                          be omitted. In this case, port number 2784 is assumed
  410.                          [This may change!].
  411.                          
  412.  
  413.   See also: WWW addressing in general , HTTP protocol .
  414.                          
  415.  
  416.    _________________________________________________________________
  417.    
  418.  
  419.                                                                          Tim BL
  420.                                                                                
  421.  
  422.                              W3 ADDRESSES OF FILES
  423.                                        
  424.  
  425.    The format of a hypertext reference to a file is an extension of the unix
  426.    naming system. The full explicit format is:
  427.    
  428.  
  429.        file :  //  node /  directories /  name
  430.    
  431.  
  432.     The actual protocols used by the client depend on the implementation of the
  433.    browser and the environment. Typically, the browser will check to see
  434.    whether the node is the local node,  or a node for which files are available
  435.    mounted in some form of distributed file system.  If neither of these are
  436.    the case, then the browser may try rpc, anonymous FTP or other protocols.
  437.    
  438.  
  439. Examples
  440.  
  441.  
  442.          file://cernvax.cern.ch/usr/lib/WWW/defaut.html
  443.  
  444.    This is a fully qualified file name.
  445.    
  446.  
  447.  
  448.          fred.html
  449.  
  450.    This relative name , used within a file, will refer to a file of the same
  451.    node and directory as that file, but the name fred.html.
  452.    
  453.  
  454. Improvements : Directory access
  455.  
  456.    The final file name should be optional. If the address ends with a '/', the
  457.    browser should retrieve the contents of the specified directory and generate
  458.    a page of virtual hypertext pointing to its contents. In addition, it could
  459.    display an information file contained in that directory, if any is present.
  460.    Suggested file names to search for in order : README.html, *README*.html,
  461.    README, *README*, *readme*.
  462.    
  463.  
  464.    
  465.  
  466.    
  467.  
  468.                         HYPERTEXT ADDRESS FOR NET NEWS
  469.                                        
  470.  
  471.    The format of a hypertext reference to information in the internet/usenet
  472.    news system can take any of the following forms:
  473.    
  474.  
  475.   news: newsgroup         This refers to a list of articles currently available
  476.                          in the given newsgroup. The newsgroup is a series of
  477.                          alphanumeric characters and dots.
  478.                          
  479.  
  480.   news:*                  This refers to a list of valid newsgroups.
  481.                          
  482.  
  483.   news: message_id        This refers to a given article explicitly. The
  484.                          message_id is optionally surrounded by angle brackets,
  485.                          and must contain an @ sign.
  486.                          
  487.  
  488.   
  489.  
  490.                          
  491.  
  492.    Possible extensions to this are more generous wildcarding for the list of
  493.    newsgroups. It takes too long to load the whole list, and it would be more
  494.    useful to be able to browse through a set of newsgroups.
  495.    
  496.  
  497.     There is no way of referring to "unread" articles. Keeping track of this is
  498.    the job of the browser.
  499.    
  500.  
  501. Examples
  502.  
  503.  
  504.          news:<12345678@cernvax.cern.ch>
  505.  
  506.          news:12345678@cernvax.cern.ch
  507.  
  508.    These addresses both refer to the same (imaginary!) article by its unique
  509.    message-id.
  510.    
  511.  
  512.  
  513.  
  514. news:comp.sys.next.announce
  515.  
  516.    This refers to a list of articles in the newsgroup comp.sys.next.announce.
  517.    The list is, of course, a list of references to article by message-id.
  518.    
  519.  
  520.                                TELNET ADDRESSING
  521.                                        
  522.  
  523.    A telnet address is a spcecial case of a W3 address.
  524.    
  525.  
  526.     When a telnet address is used, information can only be rertrieved using an
  527.    interactive telnet session. This has the disadvantage that information
  528.    cannot be indexed, searched, etc automatically, nor can it be gatewayed into
  529.    other systems.  The telnet addressing form is used to allow a pointer to
  530.    information systems such as library information systems which have not been
  531.    gatewayed into the web properly yet.
  532.    
  533.  
  534.     The syntax is, with [] indicating optional parts (see full BNF)
  535.    
  536.  
  537.  
  538.         telnet : / /  [ user @ ] host  [ : port ]
  539.  
  540.    There should be no spaces. For example, the following are valid telnet
  541.    addresses:
  542.    
  543.  
  544.  
  545.         telnet://www@info.cern.ch:23
  546.  
  547.         telnet://www@info.cern.ch
  548.  
  549.         telnet://info.cern.ch
  550.  
  551.   user                   is the optional name of the user to be used for login.
  552.                          If the username  is omitted, then so must be the "@"
  553.                          sign. This is equivalent to the argument used with the
  554.                          -l option on the ucb telnet command. When the username
  555.                          is omitted, some access servers will prompt for a
  556.                          username and password.
  557.                          
  558.  
  559.   host                   This is the name of the server in internet form. A
  560.                          numeric form (e.g. 128.141.201.74) may be used, by the
  561.                          domain name form (e.g.  info.cern.ch) is preferred.
  562.                          The host is mandatory.
  563.                          
  564.  
  565.   port                   This is a numeric port number. If a non-numeric string
  566.                          is used, it must be a defined service name. Note that
  567.                          as there is no central repository for service names
  568.                          (they are defined locaaly for each host),  a service
  569.                          name is NOT an appropriate way to specify a port
  570.                          number for a hypertext address. If the port number is
  571.                          omitted the preceding colon must also be omitted. In
  572.                          this case, port number 23 is assumed.
  573.                          
  574.  
  575.    _________________________________________________________________
  576.    
  577.  
  578.                                                                          Tim BL
  579.                                                                                
  580.  
  581.                                GOPHER ADDRESSING
  582.                                        
  583.  
  584.    Gopher addresses indicate that the gopher protocol should be used to access
  585.    the information.  The Gopher protocol is a simple internet protocol similar
  586.    to HTTP . It allows the transfer of menus or plain text files.  (HTTP
  587.    expresses both menus and plain text files as special cases of hypertext
  588.    files). See the gopher protocol notes .
  589.    
  590.  
  591.     The syntax is, with [] indicating optional parts (see BNF )
  592.    
  593.  
  594.  
  595.         gopher:// hostname [: port ] [/gtype/ [selector] ] [ ? search ]
  596.  
  597.    There should be no spaces. For example, the following are valid addresses:
  598.    
  599.  
  600.  
  601.         gopher://gopher.micro.umn.edu:70
  602.  
  603.         gopher://gopher.micro.umn.edu:70/1/
  604.  
  605.         gopher://gopher.micro.umn.edu:70
  606.  
  607.    The W3 address for a gopher item may be derived from the fields of a gopher
  608.    menu line which has the format
  609.    
  610.  
  611.   host                    This is the name of the server in internet form. A
  612.                          numeric form (e.g. 128.141.201.74) may be used, by the
  613.                          domain name form (e.g. info.cern.ch) is preferred. The
  614.                          hostname is mandatory.
  615.                          
  616.  
  617.   port                    This is a numeric port number. If a non-numeric
  618.                          string is used, it must be a defined service name.
  619.                          Note that as there is no central repository for
  620.                          service names (they are defined locaaly for each
  621.                          host), a service name is NOT an appropriate way to
  622.                          specify a port number for a hypertext address. If the
  623.                          port number is omitted the preceding colon must also
  624.                          be omitted. In this case, port number 70 is assumed.
  625.                          
  626.  
  627.   gtype                   This is a gopher item type number, a (hopefully
  628.                          printable!) ASCII character.  Currently these types
  629.                          are all ASCII decimal digit characters. Character "0"
  630.                          (hex 30)  signifies a plain text file. Character "1"
  631.                          signifies a Menu.  Character "7" signifies a
  632.                          searchable index.  Character "8" should not be used in
  633.                          a W3 address: use telnet addressing instead.  In
  634.                          general W3 terms, the type is the first part of the
  635.                          path. The rest of the path is the gopher selector
  636.                          string. The type field is a hint to the client as to
  637.                          how to represent the anchor, and how to follow it.
  638.                          
  639.  
  640.   selector                This is the string to be sent to the gopher server to
  641.                          identify the information required.
  642.                          
  643.  
  644.    _________________________________________________________________
  645.    
  646.  
  647.                                                                          Tim BL
  648.                                                                                
  649.  
  650.                           ESCAPING ILLEGAL CHARACTERS
  651.                                        
  652.  
  653.    The W3 address syntax allows a path to contain most printable ASCII
  654.    characters, but some are inevitably used for punctuation are excluded. W3
  655.    addresses are sometimes used to represent addresses in some other space.
  656.    This happens when an HTTP server, for example, uses file names as its
  657.    document names, or when addresses from some other protocol (Gopher, WAIS,
  658.    etc) are mapped into the W3 web.
  659.    
  660.  
  661.     In these cases, a convention is normally used to map illegal characters in
  662.    these "foreign" names onto the allowed set.
  663.    
  664.  
  665.     In the case of an HTTP server,  any mapping may be used.
  666.    
  667.  
  668.     A suitable convention is that a percent sign (%) followed by two
  669.    hexadecimal digits (0-9 or a-f)  stands for the single character with ASCII
  670.    hexadecimal code represented by those two digits (Most significant digit
  671.    first).
  672.    
  673.  
  674.     A percent sign itself must therefore be represented by %25, as 25 hex is
  675.    the ASCII code for "%".
  676.    
  677.  
  678.     _________________________________________________________________
  679.    
  680.  
  681.                                                                          Tim BL
  682.                                                                                
  683.  
  684.                             W3 ADDRESS SYNTAX: BNF
  685.                                        
  686.  
  687.    This is a BNF-like description of the W3 addressing syntax . We use a
  688.    vertical line "|" to indicate alternatives, and [brackets] to indicate
  689.    optional parts.   Spaces are representational only: no spaces are actually
  690.    allowed within a W3 address. Single letters stand for single letters. All
  691.    words of more than one letter below are entites described elsewhere in the
  692.    syntax description.  (Entity names are here linked to their definitions,
  693.    probably making this unreadable with the line mode browser.)
  694.    
  695.  
  696.     An absolute address specified in a link is an anchoraddress . The address
  697.    which is passed to a server is a docaddress .
  698.    
  699.  
  700.   anchoraddress           docaddress [ # anchor ]
  701.                          
  702.  
  703.   docaddress              httpaddress | fileaddress | newsaddress |
  704.                          telnetaddress | gopheraddress
  705.                          
  706.  
  707.   httpaddress             h t t p :   / / hostport  [  / path ] [ ? search ]
  708.                          
  709.  
  710.   fileaddress             f i l e : / / host / path
  711.                          
  712.  
  713.   newsaddress            n e w s : groupart
  714.                          
  715.  
  716.   groupart               * | group | article
  717.                          
  718.  
  719.   group                  ialpha [ . group ]
  720.                          
  721.  
  722.   article                xalphas @ host
  723.                          
  724.  
  725.   telnetaddress           t e l n e t : / / [ user @ ] hostport
  726.                          
  727.  
  728.   gopheraddress           g o p h e r : / / hostport  [/ gtype  [ / selector ]
  729.                          ] [ ? search ]
  730.                          
  731.  
  732.   hostport                host [ : port ]
  733.                          
  734.  
  735.   host                    hostname | hostnumber
  736.                          
  737.  
  738.   hostname                ialpha [  .  hostname ]
  739.                          
  740.  
  741.   hostnumber              digits . digits . digits . digits
  742.                          
  743.  
  744.   port                    digits
  745.                          
  746.  
  747.   selector                path
  748.                          
  749.  
  750.   path                    void |  xalphas  [  / path ]
  751.                          
  752.  
  753.   search                  xalphas [ + search ]
  754.                          
  755.  
  756.   user                    xalphas
  757.                          
  758.  
  759.   anchor                  xalphas
  760.                          
  761.  
  762.   gtype                   xalpha
  763.                          
  764.  
  765.   xalpha                  alpha | $ | _ | @ | ! | % | ^ | | * |  (  |  ) | . |
  766.                          digit
  767.                          
  768.  
  769.   xalphas                 xalpha [ xalphas ]
  770.                          
  771.  
  772.   ialpha                 alpha [ xalphas ]
  773.                          
  774.  
  775.   alpha                   a | b | c | d | e | f | g | h | i | j | k | l | m | n
  776.                          | o | p | q | r | s | t | u | v | w | x | y | z | A |
  777.                          B | C | D | E | F | G | H | I | J | K | L | M | N  | O
  778.                          | P | Q | R | S | T | U | V | W | X | Y | Z
  779.                          
  780.  
  781.   digit                   0 |1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
  782.                          
  783.  
  784.   digits                  digit [ digits ]
  785.                          
  786.  
  787.   alphanum                alpha | digit
  788.                          
  789.  
  790.   alphanums               alphanum [ alphanums ]
  791.                          
  792.  
  793.   void
  794.                          
  795.  
  796.   See also: General description of this syntax, Escaping conventions.
  797.                          
  798.  
  799.    _________________________________________________________________
  800.    
  801.  
  802.                                                                          Tim BL
  803.                                                                                
  804.  
  805.                                      HTML
  806.                                        
  807.  
  808.    The WWW system uses marked-up text to represent a hypertext document for
  809.    transmision over the network. The hypertext mark-up language is an SGML
  810.    format. This defines the basic syntax used. The particular language, the set
  811.    of tags and the rules about their use, and their significance is not part of
  812.    the SGML standard. There being no standard on this, we have adopted a set
  813.    which seems sensible. We call them HTML -- hypertext markup language. HTML
  814.    is not an alternative to SGML, it is a particular format within the SGML
  815.    rules (an SGML "DTD"). HTML parsers should ignore tags which they do not
  816.    understand, and ignore attributes which they do not understand of tags which
  817.    they do understand.
  818.    
  819.  
  820.     See also:
  821.    
  822.  
  823.   The tags                A list of the tags used in HTML with their
  824.                          significance.
  825.                          
  826.  
  827.   Example                 A file containing a variety of tags used for test
  828.                          purposes.
  829.                          
  830.  
  831. Default text
  832.  
  833.    Unless otherwise defined by tags, text is transmitted as a stream of lines.
  834.    The division of the stream of characters into lines is arbitrary, and only
  835.    made in order to allow the text to be passed through systems which can only
  836.    handle text with a limited line length. The recommended line length for
  837.    transmission is 80 characters. The division into lines has no significance
  838.    (except in the case of  example sections and PLAINTEXT ) apart from
  839.    indicating a word end. Line breaks between tags have no significance.
  840.    
  841.  
  842.                                    HTML TAGS
  843.                                        
  844.  
  845.    This is a list of tags used in the HTML language.  Each tag starts with a
  846.    tag opener (a less than sign) and ends with a tag closer (a greater than
  847.    sign).   Many tags have corresponding closing tags which identical except
  848.    for a slash after the tag opener. (For example, the TITLE tag).
  849.    
  850.  
  851.     Some tags take parameters, called attributes. The attributes are given
  852.    after the tag, separated by spaces. Certain attributes have an effect simply
  853.    by their presence, others are followed by an equals sign and a value. (See
  854.    the Anchor tag, for example). The names of tags and attributes are not case
  855.    sensitive: they may be in lower, upper, or mixed case with exactly the same
  856.    meaning.  (In this document they are generally represented in upper case.)
  857.    
  858.  
  859.     Currently HTML documents are transmitted without the normal SGML framing
  860.    tags, but if these are included parsers will ignore them.
  861.    
  862.  
  863. Title
  864.  
  865.    The title of a document is given between title tags:
  866.    
  867.  
  868.  
  869.         <TITLE> ... </TITLE>
  870.  
  871.    The text between the opening and the closing tags is a title for the
  872.    hypertext node. There should only be one title in any node. It should
  873.    identify the content of the node in a fairly wide context, and should
  874.    ideally fit on one line.
  875.    
  876.  
  877.     The title is not strictly part of the text of the document, but is an
  878.    attribute of the node. It may not contain anchors, paragraph marks, or
  879.    highlighting. the title may be used to identify the node in a history list,
  880.    to label the window displaying the node, etc. It is not normally displayed
  881.    in the text of a document itself. Contrast titles with headings .
  882.    
  883.  
  884. Next ID
  885.  
  886.    This tag takes a  single attribute which is the number of the next
  887.    document-wide numeric identifier to be allocated (not good SGML). Note that
  888.    when modifying a document,  old anchor ids should not be reused, as there
  889.    may be references stored elsewhere which point to them.  This is read and
  890.    generated by hypertext editors. Human writers of HTML usually use mnemonic
  891.    alpha identifiers.  Browser software may ignore this tag. Example of use:
  892.    
  893.  
  894.  
  895.         <NEXTID 27>
  896.  
  897. Base Address
  898.  
  899.    Anchors specify addresses of other documents, in a from relative to the
  900.    address of the current document. Normally, the address of a document is
  901.    known to the browser because it was used to access the document. However, is
  902.    a document is mailed, or is somehow visible with more than one address (for
  903.    example, via its filename and also via its library name server catalogue
  904.    number), then the browser needs to know the base address in order to
  905.    correctly deduce external document addresses.
  906.    
  907.  
  908.     The format of this tag is not yet specified.
  909.    
  910.  
  911. Anchors
  912.  
  913.    The format of an anchor is as follows:
  914.    
  915.  
  916.  
  917.         <A NAME=xxx HREF=XXX> ... </A>
  918.  
  919.    The text between the opening tag and the closing tag is either the start or
  920.    destination (or both) of a link. Attributes of the anchor tag are as
  921.    follows.
  922.    
  923.  
  924.   HREF                    If the HREF attribute is present, the anchor is
  925.                          senstive text: the start of a link. If the reader
  926.                          selects this text,  he should be presented with
  927.                          another document whose network address is defined by
  928.                          the value of the HREF attribute . The format of the
  929.                          network address is specified elsewhere . This allows
  930.                          for the form HREF=#identifier to refer to another
  931.                          anchor in the same document. If the anchor is in
  932.                          another document, the atribute is a relative name ,
  933.                          relative to the documents address (or specified base
  934.                          address if any).
  935.                          
  936.  
  937.   NAME                    The attribute NAME allows the anchor to be the
  938.                          destination of a link. The value of the parameter is
  939.                          that part of a hypertext address which follows the
  940.                          hash sign.
  941.                          
  942.  
  943.   TYPE                    An attribute TYPE may give the relationship described
  944.                          by the hyertext link. The type is expressed by a
  945.                          string for extensibility.  Strings for types with
  946.                          particular semantics will be registered by the W3
  947.                          team. The default relationship if none other is given
  948.                          is void.
  949.                          
  950.  
  951.    All attributes are optional, although one of NAME and HREF is necessary for
  952.    the anchor to be useful.
  953.    
  954.  
  955. IsIndex
  956.  
  957.    This tag informs the reader that the document is an index document. As well
  958.    as reading it, the reader may use a keyword search.
  959.    
  960.  
  961.     Format:
  962.    
  963.  
  964.  
  965.         <ISINDEX>
  966.  
  967.    The node may be queried with a keyword search by suffixing the node address
  968.    with a question mark, followed by a list of keywords separated by plus
  969.    signs. See the network address format.
  970.    
  971.  
  972. Plaintext
  973.  
  974.    This tag indicates that all following text is to be taken litterally, up to
  975.    the end of the file.  Plain text is designed to be represented in the same
  976.    way as example XMP text, with fixed width character and significant line
  977.    breaks. Format:
  978.    
  979.  
  980.  
  981.                 <PLAINTEXT>
  982.  
  983.    This tag allows the rest of a file to be read efficiently without parsing.
  984.    Its presence is an optimisation. There is no closing tag.
  985.    
  986.  
  987. Example sections
  988.  
  989.    These styles allow text of fixed-width characters to be embedded absolutely
  990.    as is into the document. The format is:
  991.    
  992.  
  993.  
  994.         <LISTING>
  995.  
  996.                 ...
  997.  
  998.         </LISTING>
  999.  
  1000.    The text between these tags is to be portrayed in a fixed width font, so
  1001.    that any formatting done by character spacing on successive lines will be
  1002.    maintained. Between the opening and closing tags:
  1003.    
  1004.  
  1005.        The text may contain any ISO Latin printable characters, including the
  1006.           tag opener, so long as it does not contain the closing tag in full.
  1007.           
  1008.  
  1009.        Line boundaries are significant, and are to be interpreted as a move to
  1010.           the start of a new line.
  1011.           
  1012.  
  1013.        The ASCII Horizontal Tab (HT) character should be interpreted as the
  1014.           smallest positive nonzero number of spaces which will leave the
  1015.           number of characters so far on the line as a multiple of 8. Its use
  1016.           is not recommended however.
  1017.           
  1018.  
  1019.    The LISTING tag is portrayed so that at least 132 characters will fit on a
  1020.    line.  The XMP tag is portrayed in a font so that at least 80 characters
  1021.    will fit on a line but is otherwise identical to LISTING. The examples of
  1022.    markup are here given using the XMP tag.
  1023.    
  1024.  
  1025. Paragraph
  1026.  
  1027.    This tag indicates a new paragraph. The exact representation of this
  1028.    (indentation,  leading, etc) is not defined here, and may be a function of
  1029.    other tags, style sheets etc. The format is simply
  1030.    
  1031.  
  1032.  
  1033.         <P>
  1034.  
  1035.    (In SGML terms, paragraph elements are transmitted in minimised form).
  1036.    
  1037.  
  1038. Headings
  1039.  
  1040.    Several levels (at least six) of heading are supported. Note that a
  1041.    hypertext document tends to need less levels of  heading than a normal
  1042.    document whose only structure is given by the nesting of headings. H1 is the
  1043.    highest level of heading, and is recommened for the start of a hypertext
  1044.    node.   It is suggested that the first heading be one suitable for a reader
  1045.    who is already browsing in related information, in contrast to the title tag
  1046.    which should identify the node in a wider context.
  1047.    
  1048.  
  1049.  
  1050.         <H1>, <H2>, <H3>, <H4>, <H5>, <H6>
  1051.  
  1052.    These tags are kept as defined in the CERN SGML guide. Their definition is
  1053.    completely historical, deriving from the AAP tag set.  A difference is that
  1054.    HTML documents allow headings to be terminated by  closing tags:
  1055.    
  1056.  
  1057.  
  1058.         <H2>Second level heading</h2>
  1059.  
  1060. Highlighting
  1061.  
  1062.    The highlighted phrase tags may occur in normal text, and may be nested. For
  1063.    each opening tag there must follow a corresponding closing tag. NOT
  1064.    CURRENTLY USED.
  1065.    
  1066.  
  1067.  
  1068.  
  1069.         <HP1>...</HP1>   <HP2>... </HP2> etc.
  1070.  
  1071. Glossaries
  1072.  
  1073.  
  1074.    A glosary (or definition list) is a list of paragraphs each of which has a
  1075.    short title alongside it.  Apart from glossaries, this format is useful for
  1076.    presenting a set of named elements to the reader. The format is as follows:
  1077.    
  1078.  
  1079.  
  1080.  
  1081.         <DL>
  1082.  
  1083.         <DT>Term<DD>definition pagagraph
  1084.  
  1085.         <DT>Term2<DD>Definition of term2
  1086.  
  1087.         </DL>
  1088.  
  1089. Lists
  1090.  
  1091.  
  1092.    A list is a sequence of paragraphs, each of which is preceded by a special
  1093.    mark or sequence number. The format is:
  1094.    
  1095.  
  1096.  
  1097.  
  1098.         <UL>
  1099.  
  1100.         <LI> list element
  1101.  
  1102.         <LI> another list element ...
  1103.  
  1104.         </LI>
  1105.  
  1106.    The opening list tag (UL for an unordered list, OL for an ordered one) must
  1107.    be immediately followed by the first list element. The representation of the
  1108.    list is not defined here, but a bulleted list for unordered lists,  and a
  1109.    sequence of numbered paraghraphs for an ordered list would be quite
  1110.    appropriate.
  1111.    
  1112.  
  1113.     "OL" IS NOT CURRENTLY USED
  1114. 
  1115.